There is a growing need to provide computing devices with wide variety of communication media, particularly using wireless technologies. For example, personal computers, netbooks, laptops, smartphones, PDAs, MIDs and the like often benefit from having wireless local area network (WLAN) and BLUETOOTH® (“Bluetooth,” managed by the Bluetooth Special Interest Group) functionality. As discussed below, there are a number of factors that help facilitate the provision of these services to the computing device.
A major consideration is to ensure compatibility with existing Bluetooth implementations. For example, MICROSOFT® (“Microsoft,” Redmond, Wash.) WINDOWS® (“Windows”) supports Bluetooth functionality through a protocol known as a stack. The Windows Bluetooth stack only operates through a universal serial bus (USB) interface. Similarly, Windows software drivers require the use of this stack, and correspondingly, only function when Bluetooth is implemented over USB. The ubiquity of Windows-based computers has ensured that this method of supporting Bluetooth has been widely adopted, essentially becoming a de facto standard. Indeed, other operating systems, such as Linux, will often mimic the Windows protocols to improve compatibility. Correspondingly, compatibility with the Windows Bluetooth stack is a great practical advantage, allowing the use of a significant amount of prewritten software code.
Given the above motivations to utilize the Windows Bluetooth stack, conventional approaches to provide a device with WLAN and Bluetooth communication generally employ a USB interface to the Bluetooth hardware. One such implementation is shown in FIG. 1 which schematically depicts computing device 100 and its relevant functional components, including central processing unit (CPU) 102, the WLAN module 104 and the Bluetooth module 106. Following standard microprocessor architecture, CPU 100 is connected to the main memory 108 through front side bus 110 and the main interface between the majority of the mainboard components is a Peripheral Component Interconnect (PCI) bus or, more preferably, a Peripheral Component Interconnect Express (PCIe) bus 112. To facilitate the design of such computing devices, it will be appreciated that it is desirable to utilize the bus 112 to interface with WLAN module 104 and Bluetooth module 106. However, since the Windows Bluetooth stack does not support the direct connection of a Bluetooth module via a PCI/PCIe bus, Bluetooth module 106 is physically connected 114 to one of the USB ports 116 and 118 provided by southbridge controller 120. To implement the USB ports, southbridge controller 120 has a standard USB open host controller interface (OHCI) 122 that is compatible with the Windows Bluetooth stack and governs the operation of USB ports 116 and 118, allowing the use of a Bluetooth module adhering to the USB standards, or the connection of any other USB device.
As will be discussed more fully below, OHCI 122 is responsible for communicating with CPU 102 to manage data transfer between host computing device 100 and the USB device connected to USB port 116 or 118. Briefly, OHCI 122 employs a list processor 124 that communicates with host controller communications area (HCCA) 126, a shared location in main memory 108. Relevant USB data in main memory 108 is organized in an endpoint structure to which list processor 124 can refer to chive the transfer of data to and from host computing device 100.
The implementation shown in FIG. 1 achieves the goals of allowing the use of the Windows Bluetooth stack to enable the Bluetooth module and employs a common bus to connect the Bluetooth and WLAN modules. However, the use of a USB port is associated with notable drawbacks.
The success of the USB interface has led to a proliferation of USB devices, including keyboards, mice, speakers, cameras, and the like, all of which consume a USB port, the number of which are necessarily limited. Given the demand for USB ports presented by these peripherals, it would be desirable to avoid the use of one of the ports to provide Bluetooth communication.
Further, the need to provide a physical USB connection in the system of FIG. 1 prevents the WLAN and Bluetooth modules from being integrated onto a single chip. This in turn adds to the size and cost of the device and foregoes the resource conservation represented by a single chip solution.
Finally, the USB interface has a polling architecture. As such, OHCI 122 must continually signal the USB device with handshake packets to find out if the USB device has data to transfer. In many instances, for example, with regard to human interface devices (HIDs), the device will not have any data to transfer for significant periods of time, resulting in a negative acknowledgement. The power consumed during this condition does not result in any data transfer. Accordingly, a USB-connected Bluetooth module does not represent a very power efficient design, which can be undesirable, particularly with regard to mobile applications.
Accordingly, it would be desirable to provide a computing device with wireless communication in the form of WLAN and Bluetooth while employing a single bus interface. It would also be desirable to provide the WLAN and Bluetooth functionality without requiring the use of a physical USB port. Further, it would be desirable to provide the wireless communication while improving power efficiency. In addition, it would be desirable to provide a Bluetooth system that is compatible with existing USB standards and protocols, including the Microsoft Windows Bluetooth stack. This invention satisfies these and other needs.